home *** CD-ROM | disk | FTP | other *** search
/ Aminet 21 / Aminet 21 (1997)(GTI - Schatztruhe)[!][Oct 1997].iso / Aminet / util / sys / AllocP.lha / AllocP / AllocP.readme < prev    next >
Text File  |  1997-08-16  |  2KB  |  61 lines
  1. Short: AllocP - BetterAlloc (AllocMem/AllocVec patch) V1.2
  2. Type: util/sys
  3. Uploader: Andreas_Kleinert@t-online.de
  4. Author: Andreas_Kleinert@t-online.de
  5.  
  6.  Sometimes programs fail with a "not enough memory" error,
  7.  but after calling "avail flush" the same operation does
  8.  succeed without problems.
  9.  
  10.  Obviously AllocMem/AllocVec does not force such a "flush"
  11.  operation *and* tries to allocate memory again. Why ?
  12.  
  13.  This patch does ensure, that AllocMem/AllocVec won't
  14.  fail unless there's really no memory available, even
  15.  by flushing. This means:
  16.  
  17.     - less "out of memory" failures
  18.     - less "bad behaviour" of bad programs, which don't
  19.       check results of AllocMem/AllocVec
  20.     - no more need to call "avail flush" by hand
  21.       from the shell
  22.     - thus no more "retry" operations after "avail flush"
  23.     - no more unused libraries/devices consuming memory
  24.       when it is already low
  25.  
  26.  Additionally, it makes AllocVec aligning its allocations to
  27.  longword boundaries - at the *end* . As you know, the Alloc#?
  28.  functions always return memory starting at longword-aligned
  29.  boundaries. But since Exec just keeps a list of the free
  30.  memory and not the allocated memory, this could mean, that
  31.  the number of 1, 2 or 3 byte chunks (which would never be
  32.  used again unless their predecessors or successors are
  33.  delocated again) could increase drastically. There's no
  34.  way to bypass this for AllocMem, but for AllocVec the
  35.  requested allocation now automatically will include these
  36.  "gaps", with the following side effects:
  37.  
  38.     - less entries in the free memory list
  39.     - less memory fragmentation
  40.     - less administration overhead
  41.     - a little bit more safety with programs, which
  42.       usually overwrite AllocVec'ed buffers by 1, 2 or
  43.       3 bytes and otherwise might have produced
  44.       MungWall hits ;-)
  45.     - the latter may also be true for some cases where
  46.       programs don't align their Read/WritePixeLine8()
  47.       buffers ;-)
  48.  
  49.  
  50.  Note:  Needs V37+ and 68020.
  51.         To be put into s:user-startup, but
  52.         runable anywhere else, too.
  53.  
  54.  
  55.  You use this patch at your own risk.
  56.  No guarantee for anything.
  57.  Source code included.
  58.  
  59.  ---
  60.  All mentioned trademarks are subject to their owners.
  61.